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Factores del coste del Ciclo de Vida del Software 
El siguiente grafico, puede mostrar la distribucion del coste del ciclo de 
vida: 
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Figura 1. Distribucién del coste del ciclo de vida 


El mantenimiento del software es una importante tarea que habitualmente 
requiere entre el 70% y 80% del coste del ciclo de vida del producto. Esto 
es debido a multiples factores, entre los que podemos encontrar: 


e Inexistencia de métodos, técnicas y herramientas que puedan 
proporcionar una solucion global al mantenimiento. 

e La complejidad de los sistemas se incrementa paulatinamente por la 
realizacion de continuas modificaciones. 

¢ La documentacion del sistema es defectuosa e inexistente. 

e Se considera el mantenimiento como una actividad poco creativa, a 
diferencia del desarrollo. 

e Las actividades de mantenimiento se suelen realizar bajo presion de 
tiempo. 

¢ Poca participacion del usuario durante el desarrollo del sistema. 


Las actuaciones comunes para mantener la operatividad del software son: 


e Correccion de defectos en el software. 
e Creacion de nuevas funcionalidades en el software por nuevos 
requisitos de usuario. 


e Mejora de la funcionalidad y del rendimiento. 


La distribucion del tiempo en tareas de mantenimiento se muestra en el 
siguiente grafico: 
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Figura 2. Distribucién del tiempo en tareas de Mantenimiento 


El error que sucede habitualmente es que se dedica escaso tiempo al 
mantenimiento del software. Se planifica mas tiempo para realizar 
desarrollos (programar) que para el mantenimiento, de ahi, que luego haya 
errores de costes y de planificacién. También es importante el factor de la 
documentacion. Esta siempre tiene que estar actualizada para posibles 
cambios en el futuro. 


Técnicas del Mantenimiento del Software 


Dentro de la ingenieria del software se proporcionan soluciones técnicas 
que permiten abordar el mantenimiento de manera que su impacto en coste 
dentro del ciclo de vida sea menor. Las soluciones técnicas pueden ser de 
tres tipos: 


1. Ingenieria inversa: Analisis de un sistema para identificar sus 
componentes y las relaciones entre ellos, asi como para crear 
representaciones del sistema en otra forma o en un nivel de abstraccion 
mas elevado. 

2. Reingenieria: Modificacion de un producto software, o de ciertos 
componentes, usando para el analisis del sistema existente técnicas de 
ingenieria inversa y, para la etapa de reconstrucci6on, herramientas de 
ingenieria directa, de tal manera que se oriente este cambio hacia 
mayores niveles de facilidad en cuanto a mantenimiento, reutilizacion, 
comprension o evolucion. 

3. Reestructuraci6n del software: Cambio de representacion de un 
producto software, pero dentro del mismo nivel de abstraccion. 


El objetivos de estas técnicas es proporcionar métodos para reconstruir el 
software, ya Sea reprogramandolo, redocumentandolo, redisefandolo, o 
rehaciendo alguna/s caracteristica/s del producto. La diferencia entre las 
soluciones descritas radica en cual es el origen y cual es el destino de las 
mismas (producto inicial y/o producto final). 


Graficamente, estas tres soluciones técnicas se enmarcan en el ciclo de vida 
de la siguiente manera: 
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Figura 1. Relaciones entre los términos asociados con la Reingenieria. 


La Ingenieria directa corresponde al desarrollo del software tradicional. La 
Ingenieria Inversa es el proceso de analisis de un sistema para identificar 
sus componentes e interrelaciones y crear representaciones del sistema en 
otra forma 0 a un nivel mas alto de abstraccion. La Reingenieria es el 
examen y la alteracion de un sistema para reconstruirlo de una nueva forma 
y la subsiguiente implementacion de esta nueva forma. La Reestructuraci6n 
es la modificacion del software para hacerlo mas facil de entender y 
cambiar. 


La reingenieria hace referencia a un ciclo, esto es, se aplican técnicas de 
ingenieria inversa para conseguir representaciones de mayor abstraccion del 
producto y sobre ellas se aplican técnicas de ingenieria directa para 
redisenar 0 reimplementar el producto. 


Cualquiera de estas técnicas se puede aplicar a lo largo de todas las fases 
del ciclo de vida o bien entre algunas de sus fases. 


También existen otras tecnologias, como por ejemplo: 


e La remodularizacion: consiste en cambiar la estructura modular de un 
sistema de forma que se obtenga una nueva estructura siguiendo los 
principios del diseno estructurado. 

e Analisis de la facilidad de mantenimiento: normalmente la mayor parte 
del mantenimiento se centra relativamente en unos pocos méddulos del 


sistema. 

e Visualizacion: el proceso mas antiguo para la comprension del 
software. 

e Analisis y mediciones: son importantes tecnologias que estudian 
ciertas propiedades de los programas. 


éQué es la Ingenieria Inversa? 


La ingenieria inversa se ha definido como el proceso de construir 
especificaciones de un mayor nivel de abstraccion partiendo del cédigo 
fuente de un sistema software o cualquier otro producto (se puede utilizar 
como punto de partida cualquier otro elemento de diseno, etc.). 


Estas especificaciones pueden volver ser utilizadas para construir una nueva 
implementacion del sistema utilizando, por ejemplo, técnicas de ingenieria 
directa. 


Beneficios de Ingenieria Inversa 


La aplicacion de ingenieria inversa nunca cambia la funcionalidad del 
software sino que permite obtener productos que indican cémo se ha 
construido el mismo. Se realiza permite obtener los siguientes beneficios: 


e Reducir la complejidad del sistema: al intentar comprender el software 
se facilita su mantenimiento y la complejidad existente disminuye. 

e Generar diferentes alternativas: del punto de partida del proceso, 
principalmente cdédigo fuente, se generan representaciones graficas lo 
que facilita su comprension. 

e Recuperar y/o actualizar la informacién perdida (cambios que no se 
documentaron en su momento): en la evolucion del sistema se realizan 
cambios que no se suele actualizar en las representaciones de nivel de 
abstraccion mas alto, para lo cual se utiliza la recuperacion de disefo. 

e Detectar efectos laterales: los cambios que se puedan realizar en un 
sistema puede conducirnos a que surjan efectos no deseados, esta serie 
de anomalias puede ser detectados por la ingenieria inversa. 

e Facilitar la reutilizaci6n: por medio de la ingenieria inversa se pueden 
detectar componentes de posible reutilizaci6n de sistemas existentes, 
pudiendo aumentar la productividad, reducir los costes y los riesgos de 
mantenimiento. 


La finalidad de la ingenieria inversa es la de desentrafar los misterios y 
secretos de los sistemas en uso a partir del codigo. Para ello, se emplean 


una serie de herramientas que extraen informacion de los datos, 
procedimientos y arquitectura del sistema existente. 


Tipos de Ingenieria Inversa 
La ingenieria inversa puede ser de varios tipos: 


e Ingenieria inversa de datos: Se aplica sobre algun cdédigo de bases 
datos (aplicacion, codigo SQL, etc) para obtener los modelos 
relacionales o sobre el modelo relacional para obtener el diagrama 
entidad-relacion 

e Ingenieria inversa de ldgica o de proceso: Cuando la ingenieria inversa 
se aplica sobre codigo de un programa para averiguar su logica o sobre 
cualquier documento de diseno para obtener documentos de analisis 0 
de requisitos. 

e Ingenieria inversa de interfaces de usuario: Se aplica con objeto de 
mantener la l6gica interna del programa para obtener los modelos y 
especificaciones que sirvieron de base para la construccion de la 
misma, con objeto de tomarlas como punto de partida en procesos de 
ingenieria directa que permitan modificar dicha interfaz. 


Herramientas para la Ingenieria Inversa 


Los Depuradores 


Un depurador es un programa que se utiliza para controlar otros programas. 
Permite avanzar paso a paso por el cédigo, rastrear fallos, establecer puntos 
de control y observar las variables y el estado de la memoria en un 
momento dado del programa que se esté depurando. Los depuradores son 
muy valiosos a la hora de determinar el flujo logico del programa. 


Un punto de ruptura (breakpoint) es una instruccion al depurador que 
permite parar la ejecucion del programa cuando cierta condici6n se cumpla. 
Por ejemplo, cuando un programa accede a cierta variable, o llama a cierta 
funcion de la API, el depurador puede parar la ejecucion del programa. 


Algunos depuradores de Windows son: 


e OllyDbg — es un potente depurador con un motor de ensamblado y 
desensamblado integrado. Tiene numerosas otras caracteristicas 
incluyendo un precio de 0 $. Muy util para parcheado, desensamblado 
y depuracion. 

e WinDBG - es una pieza de software gratuita de Microsoft que puede 
ser usada para depuracion local en modo usuario, 0 incluso depuracion 
remota en modo kernel. 


Las Herramientas de Inyecci6n de Fallos 


Las herramientas que pueden proporcionar entradas malformadas con 
formato inadecuado a procesos del software objetivo para provocar errores 
son una clase de herramientas de insercion de fallos. Los errores del 
programa pueden ser analizados para determinar si los errores existen en el 
software objetivo. Algunos fallos tienen implicaciones en la seguridad, 
como los fallos que permiten un acceso directo del asaltante al ordenador 
principal o red. Hay herramientas de inyeccion de fallos basados en el 
anfitridn que funcionan como depuradores y pueden alterar las condiciones 
del programa para observar los resultados y también estan los inyectores 
basados en redes que manipulan el trafico de la red para determinar el 
efecto en el aparato receptor. 


Los Desensambladores 


Se trata de una herramienta que convierte codigo maquina en lenguaje 
ensamblador. El lenguaje ensamblador es una forma legible para los 
humanos del cédigo maquina. Los desensambladotes revelan que 
instrucciones maquinas son usadas en el cédigo. El cédigo maquina 
normalmente es especifico para una arquitectura dada del hardware. De 
forma que los desensambladotes son escritor expresamente para la 
arquitectura del hardware del software a desensamblar. 


Algunos ejemplos de desensambladores son: 


e IDA Pro > es un desensamblador profesional extremadamente 
potente. La parte mala es su elevado precio. 

e PE Explorer — es un desensamblador que “se centra en facilidad de 
uso, Claridad y navegacio6n”. No es tan completo como IDA Pro, pero 
tiene un precio mas bajo. 

e IDA Pro Freeware 4.1 — se comporta casi como IDA Pro, pero solo 
desensambla cédigo para procesadores Intel x86 y solo funciona en 
Windows. 

e Bastard Disassembler > es un potente y programable desensamblador 
para Linux y FreeBSD. 

e Ciasdis > esta herramienta basada en Forth permite construir 
conocimiento sobre un cuerpo de cédigo de manera interactiva e 
incremental. Es unico en que todo el cddigo desensamblado puede ser 
re-ensamblado exactamente al mismo codigo. 


Los compiladores Inversos 0 Decompiladores 


Un decompilador es una herramienta que transforma cédigo en 
ensamblador o cédigo maquina en cédigo fuente en lenguaje de alto nivel. 
También existen decompiladores que transforman lenguae intermedio en 
codigo fuente en lenguaje de alto nivel. Estas herramientas son sumamente 
utiles para determinar la logica a nivel superior como bucles o 
declaraciones if-then de los programas que son decompilados. Los 
decompiladores son parecidos a los desensambladotes pero llevan el 
proceso un importante paso mas alla. 


Algunos decompiladores pueden ser: 


e DCC Decompiler — es una exacelente perspectiva tedrica a la 
descompilacion, pero el descompilador solo soporta programas 
MSDOS. 

¢ Boomerang Decompiler Project — es un intento de construir un 
potente descompilador para varias maquinas y lenguajes. 


e Reverse Engineering Compiler (REC) — es un potente 
“descompilador” que descompila codigo ensamblador a una 
representacion del codigo semejante a C. El cddigo esta a medio 
camino entre ensamblador y C, pero es mucho mas legible que el 
ensamblador puro. 


Las Herramientas CASE 


Las herramientas de ingenieria de sistemas asistida por ordenador 
(Computer-Aided Systems Engineering — CASE) aplican la tecnologia 
informatica a las actividades, las técnicas y las metodologias propias de 
desarrollo de sistemas para automatizar 0 apoyar una o mas fases del ciclo 
de vida del desarrollo de sistemas. En el caso de la ingenieria inversa 
generalmente este tipo de herramientas suelen englobar una o mas de las 
anteriores junto con otras que mejoran el rendimiento y la eficiencia. 


Ingenieria Inversa de Procesos 


La primera actividad real de la ingenieria inversa comienza con un intento 
de comprender y posteriormente, extraer las abstracciones de 
procedimientos representadas por el codigo fuente. Para comprender las 
abstracciones de procedimientos, se analiza el codigo en distintos niveles de 
abstraccion: sistema, programa, componente, configuracion y sentencia. 


Antes de iniciar el trabajo de ingenieria inversa detallado debe 
comprenderse totalmente la funcionalidad general de todo el sistema de 
aplicaciones sobre el que se esta operando. Esto es lo que establece un 
contexto para un analisis posterior, y proporciona ideas generales acerca de 
los problemas de interoperabilidad entre aplicaciones dentro del sistema. 
Asi pues, cada uno de los programas de que consta el sistema de 
aplicaciones representara una abstraccion funcional con un elevado nivel de 
detalle, creandose un diagrama de bloques como representacion de la 
iteraciOn entre estas abstracciones funcionales. Cada uno de los 
componentes de estos diagramas efectua una subfuncion, y representa una 
abstraccion definida de procedimientos. En cada componente se crea una 
natrativa de procesamientos. En algunas situaciones ya existen 
especificaciones de sistema, programa y componente. Cuando ocurre tal 
cosa, se revisan las especificaciones para preciar si se ajustan al codigo 
existente, descartando posibles errores. 


Todo se complica cuando se considera el codigo que reside en el interior del 
componente. El ingeniero busca las secciones del cédigo que representan 
las configuraciones genéricas de procedimientos. En casi todos los 
componentes, existe una seccion de codigo que prepara los datos para su 
procesamiento (dentro del componente), una seccion diferente de cddigo 
que efectua el procesamiento y otra seccion de cddigo que prepara los 
resultados del procesamiento para exportarlos de ese componente. En el 
interior de cada una de estas secciones, se encuentran configuraciones mas 
pequenas. Por ejemplo, suele producirse una verificacion de los datos y una 
comprobacion de los limites dentro de la secci6n de cédigo que prepara los 
datos para su procesamiento. 


Para los sistemas grandes, la ingenieria inversa suele efectuarse mediante el 
uso de un enfoque semiautomatizado. Las herramientas CASE se utilizan 


para “analizar” la semantica del codigo existente. La salida de este proceso 
se pasa entonces a unas herramientas de reestructuracion y de ingenieria 
directa que completaran el proceso de reingenieria. 


Cuando aplicar ingenieria inversa de procesos 


Cuando la ingenieria inversa se aplica sobre codigo de un programa para 
averiguar su logica o sobre cualquier documento de diseno para obtener 
documentos de analisis 0 de requisitos se habla de ingenieria inversa de 
procesos. 


Habitualmente, este tipo de ingenieria inversa se usa para: 


e Entender mejor la aplicacion y regenerar el cddigo. 

e Migrar la aplicacion a un nuevo sistema operativo. 

e Generar/completar la documentacion. 

e¢ Comprobar que el cddigo cumple las especificaciones de diseno. 


La informacion extraida son las especificaciones de diseno: se crean 
modelos de flujo de control, diagramas de disefio, documentos de 
especificacion de disefio, etc. y pudiendo tomar estas especificaciones como 
nuevo punto de partida para aplicar ingenieria inversa y obtener 
informacion a mayor nivel de abstraccion. 


~Como hacemos la ingenieria inversa de procesos? 


A la hora de realizar ingenieria inversa de procesos se suelen seguir los 
siguientes pasos: 


1. Buscamos el programa principal. 

2. Ignoramos inicializaciones de variables, etc. 

3. Inspeccionamos la primera rutina llamada y la examinamos si es 
importante. 

4. Inspeccionamos las rutinas llamadas por la primera rutina del 
programa principal, y examinamos aquéllas que nos parecen 
importantes. 

5. Repetimos los pasos 3-4 a lo largo del resto del software. 


6. Recopilamos esas rutinas “importantes”, que se llaman componentes 
funcionales. 

7. Asignamos significado a cada componente funcional, esto es (a) 
explicamos qué hace cada componente funcional en el conjunto del 
sistema y (b) explicamos qué hace el sistema a partir de los diferentes 
componentes funcionales. 


A la hora de encontrar los componentes funcionales hay que tener en cuenta 
que los médulos suelen estar ocupados por componentes funcionales. 
Ademas, suele haber componentes funcionales cerca de grandes zonas de 
comentarios y los identificadores de los componentes funcionales suelen ser 
largos y formados por palabras entendibles. 


Una vez encontrados los posibles componentes funcionales, conviene 
repasar la lista teniendo en cuenta que un componente es funcional cuando 
Un componente es funcional cuando su ausencia impide seriamente el 
funcionamiento de la aplicacion, dificulta la legibilidad del cédigo, impide 
la comprension de todo o de otro componente funcional 0 cuando hace caer 
a niveles muy bajos la calidad, fiabilidad, mantenibilidad, etc. 


Vamos a ver cOmo a partir de un codigo java como se puede realizar 
Ingenieria Inversa de Procesos. Tenemos dos clases (Persona y Trabajador) 


Class Persona { 

protected String nombre; 

protected int edad; 

protected int seguroSocial; 
protected String licenciaConducir; 


public Persona(String nom, int ed, int seg, String 
ee yet 


set(nom, ed); seguroSocial = seg; licenciaConducir 
= lic; } 


public Persona() { 
PersonaCnuliy--©,..0, null); 3 

public int setNombre(String nom) { 
nombre = nom; return 1; } 

public int setEdad(int ed) { 

edad = ed; return 1; } 

public void set(String nom, int ed) { 
setNombre(nom); setEdad(ed); } 

public void set(int ed, String nom) { 
setNombre(nom); setEdad(ed); } 

t 

Class Trabajador extends Persona { 
DiaVabe string empresa, 

private int salario; 

public Trabajador(String emp, int sal) { 
empresa = emp; salario = sal; } 
publac hrabajader( ) 4 

Ea SCM Oise 

pUbIaG Ane Sekenpresa string enp) 


empresa = emp; return 1; } 


public int setSalario(int sal) { 
salario = sal; return 1; } 

public void set(String emp, int sal) { 
setEmpresa(emp); setSalario(sal); } 
Dubie Vvold sen(Gint: sal, Sthing emp) 4 
setEmpresa(emp); setSalario(sal); } 


} 


Si realizamos Ingenieria Inversa, el diagrama UML seria el siguiente: 


®% Persona 
: String 


® Trabajador 
: Integer & empresa : String 
& seguroSocial —: Integer & salario : Integer 


& licenciaConducir : String ® setEmpresa(String empresa) —_; Integer 
® setNombre(String nombre): ® setSalariocint salario) : Integer 
® setEdad(int edad) : ® set(String empresa, int salario) : void 
® set(String nombre int edad) : ® set(int salario, String empresa) : void 

® set(int edad, String nombre) : 


Figura 1. Diagrama de clase generado a partir del cédigo Java 


Ingenieria Inversa de Datos 


La Ingenieria Inversa de Bases de Datos es el conjunto de técnicas que 
permite la obtencion de una representaciOn conceptual de un esquema de 
base de datos a partir de su codificacion. 


Sus aplicaciones son multiples: 


e Re-documentar, reconstruir y/o actualizar documentacion perdida o 
inexistente de bases de datos 

e Servir como pivote en un proceso de migracion de datos 

e Ayudar en la exploracion y extraccion de datos en bases poco 
documentadas. 


La informacion que se puede extraer, dependiendo del punto de partida 
puede ser: Entidad, relaciones, atributos, claves primarias 0 ajenas, etc., a 
partir de estos elementos se crean modelos de datos, como por ejemplo 
Diagramas entidad-relacion. 


A continuacion se muestra un ejemplo grafico de Ingenieria Inversa de 
Datos. A partir del codigo fuente (disefio fisico), se realiza Ingenieria 
Inversa y se obtiene el Disefio Logico. A este disefio se vuelve a aplicar 
Ingenieria Inversa y se obtiene el Diseno Conceptual. 


FEAEEEESEET SARL AS FEEEEEEEEE 


CREATE TABLE autor 
(nombre_a nombres, 
nacionalidad nacionalidades, 


PRIMARY KEY (nombre _a)) 

<> Lites 
CREATE TABLE trahaja (ON) aN) 
(nombre_a nombres, 
nombre_i instituciones, Sear 


PRIMARY KEY (nombre _a,nombre_i), 
FOREIGN KEY (nombre _a) REFERENCES 
autor ON UPDATE CASCADE) 


CREATE TABLE institucion 

(nombre_i _instituciones, 

Dir lugares, 

Tel telefonos, 

PRIMARY KEY (nombre_i)) = INGENTERIA INGENIERIA 
INVERSA INVERSA 

CREATE TABLE libro 

(cod_ libro _ codigos, 

titulo titulo NOT NULL, 


Libro 
cod_libro 
titslo 


Figura 1. Ejemplo de Ingenieria Inversa de Datos 


Técnicas de la Ingenieria Inversa de Datos 


La ingenieria inversa de datos se aplica sobre algtin codigo de bases de 
datos (aplicacion, codigo SQL, etc.) para obtener los modelos relacionales o 
sobre el modelo relacional para obtener el diagrama entidad-relacion. Hay 
que tener en cuenta que la ingenieria inversa se puede dar entre distintos 
productos del ciclo de vida de una aplicacion. 


Existen muchas técnicas para hacer ingenieria inversa de base de datos, 
algunos de los cuales se pueden ver resumidos en la siguiente tabla: 


e Baltin et al (1992): 


o Suposiciones: 3FN. Consistencia en el nombrado de los atributos. 
Sin homonimos. Clave principal y clave candidata. 

o Entradas: Dependencias. Esquemas de relacion. 

o Salidas: Entidades. Relaciones binarias. Categorias. 
Generalizaciones. 

© Basado en el método de Navathe de Awongs. 


° Chiang et al (1994,1996): 


o Suposiciones: 3FN. Consistencia en el nombrado de los atributos. 
Sin errores en los atributos claves. 

o Entradas: Esquema de relacion. Instancia de datos. Dependencias. 

o Salidas: Entidades. Relaciones binarias. Generalizaciones. 
Agregaciones. 

o Caracteristicas: Requiere el conocimiento acerca del nombre de 
los atributos. Propone un marco de trabajo para la evaluacién de 
los métodos de ingenieria inversa. Identifica claramente los casos 
en los que las entradas de los humanos son necesarias. 


e Davids & Arora (1987): 


o Suposiciones: 3FN. Sin homonimos ni sindnimos. 

o Entradas: Esquemas de relacion. Restricciones de claves ajenas. 

o Salidas: Conjunto de entidades. Relaciones binarias. Relaciones 
N-aria. 


o Caracteristicas: Apunta a una transformacion reversible desde el 
esquema relacional al esquema conceptual. 


e Johannessin (1994): 


o Suposiciones: 3FN. Consultas de dominio independientes. 

o Entradas: Dependencias funcionales y de inclusi6n. Esquemas de 
relacion. 

o Salidas: Generalizaciones. Entidades. Relaciones binarias. 

o Caracteristicas: Basado en los conceptos establecidos de las teoria 
de bases de datos relacionales. Proceso de mapeo simple y 
automatico. 


e Markowitz & Makowsky (1990): 


o Suposiciones: FN Boycce-Codd. 

o Entradas: Esquemas de relaci6n. Dependencias de claves. 
Dependencias de integridad referencial. 

o Salidas: Entidades. Relaciones binarias. Generalizaciones y 
agregaciones. 

o Caracteristicas: Requiere todas las dependencias de clave. 


e Navathe & Among (1987): 


o Suposiciones: 3FN y algunos 2FN. Consistencia en el nombrado 
de atributos. Sin ambigtiedades de clave ajena. Claves candidatas 
especificas. 

o Entradas: Esquemas de relacion. 

o Salidas: Entidades. Relaciones binarias. Categorias. 
Cardinalidades. 

o Caracteristicas. Es vulnerable a la ambigtiedad en el 
reconocimiento de claves ajenas. 


e Petit et al (1996): 


o Suposiciones: 1FN. Atributos tnicos. 
o Entradas: Esquemas de relacion. Instancia de datos y codigo. 
o Salidas: Entidades. Relaciones. Generalizaciones. 


o Caracteristicas: Analiza las consultas en los programas de 
aplicacion. No pone restricciones en el nombre de los atributos. 


e Permerlani & Blaha (1993,1994): 


o Suposiciones: Sin F3N. Comprension semantica de aplicacion. 

o Entradas: Esquemas de relacion. Observaciones de patrones de 
datos. 

o Salidas: Clases. Asociaciones. Generalizaciones. Multiplicidad. 
Agregacion. 

o Caracteristicas: Requiere un alto nivel de entrada de los humanos. 
Enfatiza en el andlisis de las claves. 


e Sotou (1997,1998): 


o Suposiciones: Sin nombres unicos de atributos. Dependencias 
desconocidas. 

o Entradas: Esquema de datos. Instancia de datos. Diccionario de 
datos. 

o Salidas: Cardinalidad de las restricciones de relaciones n-arias. 

o Caracteristicas: Proceso automatizado completamente para SQL. 


Entre las distintas técnicas de Ingenieria Inversa de datos, se propone el 
método de Hainaut et al () para explicarla. 


El método pasa por dos fases. En la 1° fase se realiza la extraccion de 
estructuras y en la 2* la conceptualizacion de las mismas: 


tablas yreglasde 
integrdad 


1. FASE I: Extraccion de estructuras 


o Considerar cada fichero una posible tabla. 

o Considerar cada campo del fichero como un posible campo de la 
tabla. 

o Identificar las claves primarias. 

o Identificar claves ajenas. 

o “Filtrar” las tablas (por ejemplo, despreciar aquellos ficheros sin 
clave principal). 

o Deteccién de campos obligatorios. 

o Deteccién de asociaciones entre tablas 


2. FASE II: Conceptuacion de las estructuras 


o Sustituci6n de constructores propios del sistema real por 
constructores independientes (ej: una tabla que es un elemento 
fisico es sustituida por el concepto de entidad que es un elemento 
l6gico). 

© Deteccion y eliminacion de los constructores no semanticos del 
esquema légico, paso inverso a la optimizacién del esquema (ej: 
deshacer la normalizacién de un SGBD relacional). 


o Normalizaci6n conceptual para obtener estructuras de alto nivel. 


Ejemplo de Ingenieria Inversa de Datos 


La Ingenieria Inversa de Bases de Datos es el conjunto de técnicas que permite la obtencidn de una representacion 
conceptual de un esquema de base de datos a partir de su codificacién. 


Sus aplicaciones son multiples: Re-documentar, reconstruir y/o actualizar documentacion perdida 0 inexistente de 
bases de datos, servir como pivote en un proceso de migracion de datos, y ayudar en la exploraci6n y extraccion de 
datos en bases poco documentadas. 


Ahora se comienza a realizar el analisis por el cual obtendremos el modelo conceptual de una base de datos a partir 
de un modelo fisico. 


Esta aplicacién esta implentada en Delphi, con un Oracle Server 8i Lite, por lo tanto los ejemplos estan basados en 
dichos productos. De todas formas, el andlisis es el mismo a seguir independientemente del lenguaje o base de 
datos que utilicemos. 


Lo primero que se debe de hacer es obtener toda la informacion posible de la estructura de la base de datos (no de 
los datos que contiene), es decir, nombre de las tablas, atributos de las tablas, etc. Dicha informacion se encuentra 
almacenada en el catalogo de la base de datos (el cual se consulta facilmente utilizando SQL). La informacién 
obtenida a partir del catalogo se debe almacenar en algun lado (se suele crear una serie de clases que permitan 
almacenar toda la informacion y ademas a dichas clases se les agrega cierta funcionalidad que permita manejar 
facilmente la informacién almacenada en ellas). 


Para realizar la obtenci6n de todas las tablas que componen la base de datos se debe efectuar una consulta SQL. En 
dicha consulta se obtiene los nombres de las tablas, atributos que componen las tablas con sus caracteristicas mas 
generales (tipos de datos y si admite valores nulos). 


La consulta SQL que utilice es la siguiente: 

SELECT at.table_name, attc.column_name, attc._data_type, attc.nullable 
FROM all_tables at, all_tab_columns attc 

WHERE at.table_name = attc.table_name 


El resultado de dicha consulta sera el siguiente: por cada fila habran cuatro columnas. Las columnas significan lo 
siguiente: nombre de la tabla, nombre del atributo, tipo de dato del atributo y si el atributo puede ser nulo. Por lo 
tanto, cada tabla tendra tantas filas en el resultado de la consulta como atributos posea. 


Una vez realizada esta consulta se procede a guardarla en las estructuras de almacenamiento. Una vez hecho se 
puede analizar cuales atributos de las tablas corresponden a la clave primaria, cuales son claves fordneas y cuales 
son claves tinicas (que en el modelo de normalizacion serian las claves candidatas). 


Para obtener aquellos atributos que componen la clave primaria de una tabla dada se realiza la siguiente consulta, 
que se debe realizar para cada tabla existente en la base de datos, cambiando en la siguiente consulta NombreTabla 
por el nombre de la tabla que se consulta (a partir de este momento, cada vez que se coloque NombreTabla se 
entendera que es la tabla que nos encontramos analizando). Aqui va la consulta SQL realizada: 


SELECT column_name 
FROM all_constraints ac, all_cons_columns acc 


WHERE ac.table_name = 'NombreTabla' 


AND ac.constraint_type Pe 


AND ac.constraint_name = acc.constraint_name 


ORDER BY acc.position; 
El resultado de esta consulta es una fila para cada atributo que forma parte de la clave primaria. Dichos atributos se 
desplegaran en orden ascendente segun su posicion, para asi poder ingresarlos en el orden por el cual fueron 


definidos. 


A continuacion se obtendran los atributos que forman las claves fordneas de una tabla, y las tablas a las cuales hace 
referencia dicha clave fordnea perteneciente a una determinada tabla, que se |lamara nuevamente NombreTabla. 


SELECT ac.constraint_name, column_name, r_constraint_name 
FROM all_constraints ac, all_cons_columns acc 


WHERE ac.table_name = 'NombreTabla' 


AND ac.constraint_type RY 

AND ac.constraint_name = acc.constraint_name 

ORDER BY acc.position; 

Como resultado se obtiene una fila por cada atributo que compone a una clave fordnea. Cada constraint (clave 
foradnea en este caso) tendra tantas filas como atributos los compongan. Por cada columna tenemos la siguiente 
informacion en el siguiente orden: nombre del constraint, nombre del atributo y nombre del constraint al cual hace 
referencia. 


A partir de los constraints a los cuales se hacen referencia, se puede obtener facilmente a que tabla pertenecen por 
medio de la siguiente consulta: 


SELECT table_name 

FROM all_constraints 

WHERE constraint_name = 'NombreConstraint' 

Con la consulta anterior obtenemos a que tabla pertenece el constraint NombeConstraint y por lo tanto, si una 
clave foranea hace referencia al constraint NombreConstraint, entonces ahora sabemos a que tabla hace referencia 


dicha clave fordnea. 


Finalmente, para la carga de datos solo falta averiguar cuales son los atributos que componen a las claves tnicas. 
Para esto se realiza la siguiente consulta: 


SELECT ac.constraint_name, column_name 
FROM all_constraints ac, all_cons_columns acc 


WHERE ac.table_name = 'NombreTabla' 


AND ac.constraint_type Us 


AND ac.constraint_name = acc.constraint_name 


ORDER BY acc.position; 


La consulta anterior devuelve todas las claves tinicas que existen en una tabla. Cada clave unica tendra tantas filas 
en el resultado de la consulta como atributos la compongan. El significado de las columnas es el siguiente: nombre 
del constraint (0 sea, de la clave unica en este caso) y nombre del atributo. 


Analisis de las tablas 


A continuaci6n se presenta como determinar que representacién conceptual tiene una tabla dada. Es decir, por 
ejemplo, una tabla puede ser considerada una entidad, una relacion binaria, una relaci6n ternaria, una 
categorizacion, etc. 


En general, el siguiente andlisis debe ser realizado por todas las tablas. Como guia, se presenta un diagrama de 
flujo, que es el que se debe seguir a la hora de analizar una tabla. Es decir, a una tabla dada se le realizaran ciertas 
pruebas y en funcion de los resultados de dichas pruebas decidiremos que 'camino' del diagrama de flujo seguir. 


A continuacion se presenta el diagrama de arbol que sirve de ayuda a la hora de realizar el andlisis. 
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Figura 1. Diagrama de arbol 


Determinar si una tabla corresponde a una entidad 0 a una relacién 


Lo primero que se debe realizar en el proceso del analisis es determinar si el modelo conceptual de una tabla 
corresponde a una entidad o a una relacion. 


Para realizar dicho analisis, se intentan probar distintos casos, mediante los cuales se podra descartar las diferentes 
opciones. 


Determinar si corresponde a una entidad aislada 


Tal vez el término 'aislada' no es el mas adecuado, debido a que en un modelo relacional bien hecho, muy 
dificilmente existan tablas completamente aisladas. En este andlisis se refiere a entidades aisladas cuando una tabla 
no posee claves foraneas a otras tablas. Mediante el analisis de esta tabla no se puede saber a priori las relaciones 
en las que participa dicha tabla, pero si se podra determinar mas adelante del andlisis. Por lo tanto no es una 
entidad aislada, sino que mas bien es una potencial entidad aislada, pero no se sabra hasta finalizar el andlisis de 
todas las tablas. 


Determinar si una tabla corresponde a un entidad aislada es muy sencillo, lo inico que se debe hacer es fijarse si 
dicha tabla posee claves fordneas. En el caso de que posea estamos seguros de que no es una entidad aislada y 
podemos proseguir con el andlisis de la tabla, pero si se diera el caso que no posee ninguna clave foranea, entonces 


estamos seguros que corresponde a una entidad aislada, por lo que podemos agregar dicha tabla a nuestra 
estructura de almacenamiento entidades y pasar a analizar la siguiente tabla. 


Determinar si corresponde a una categorizacion 


Las categorizaciones se caracterizan por lo siguiente: toda la clave primaria de una tabla ‘hija’ forma una (y solo 
una) clave fordnea a la tabla 'madre'. 


Si se llega a este punto se sabe que la tabla posee por lo menos una clave foranea (por dicha razon no es 
considerada una entidad aislada). Lo primero que se debe hacer es fijarse si los atributos que componen a la clave 
primaria de la tabla componen a su vez una clave fordnea. Con esto quiero decir que los atributos que componen la 
clave primaria NO componen a mas de una clave fordnea. En el caso que los atributos que componen la clave 
primaria no compongan ninguna clave fordnea, o que compongan a mas de una clave foranea, se esta seguro de 
que no nos encontramos frente a una categorizaci6n. 


A continuacion se plantea un ejemplo sencillo de categorizaci6n mediante el uso de tres tablas: empleados, 
gerentes y secretarias. La estructura fisica de las tres tablas es la siguiente: 


Empleados Gerentes Secretarias 


Numero_Empleado (PK) Numero_Empleado (PKFK) Numero_Empleado(PKFK) 


El atributo Numero_Empleado, tanto en la tabla Gerentes como en la tabla Secretarias, forma una clave fordnea a 
la tabla Empleados. 


Debido a que tanto la tabla Gerentes como la tabla Secretarias no poseen mas claves fordneas, deducimos 
instantaneamente que no es una tabla que represente una relaci6n, sino que existe una categorizacion. Por lo tanto, 
la representacion seria la siguiente: 


Imaginemos el siguiente caso: 


Empleados Gerentes Secretarias 


Nutmero_Empleado Ntmero_Empleado Nutmero_Empleado(PKFK)Numero_Computadora(FK) 


(PK) (PKFK) 


Si se nos diera este caso debemos realizar un analisis mas profundo para poder determinar si la tabla Secretarias 
pertenece a una categorizacion, debido a que la representaci6n conceptual de esta tabla podria ser cualquiera de las 
siguientes: 


Caso 1: 


Caso 2: 


Como se puede observar, son representaciones completamente diferentes. En la primera Secretarias forma parte de 
una categorizacion, y en la segunda Secretarias es considerada una relacion entre Empleados y Computadoras, con 
cardinalidades N—1 0 1-1. 


En ocasiones es posible poder diferenciar entre los dos casos. La unica forma de hacerlo es examinando el atributo 
Ntmero_Computadora que pertenece a la tabla Secretarias y que hace referencia a la tabla Computadoras: si dicho 
atributo admite valores nulos, estamos completamente seguros que nos encontramos en el primer caso y no en el 
segundo. Esto es debido a que si Secretarias fuese una tabla que representa una relacion entre Empleados y 
Computadoras, el atributo Numero_Computadora NO podria aceptar valores nulos, debido a que por definicién, 
las relaciones binarias son pares ordenados. 


Si se nos plantea el caso de que el atributo Numero_Computadora perteneciente a la tabla Secretarias no admite 
valores nulos, es imposible diferenciar entre los dos casos que planteamos anteriormente, por lo tanto debemos 
adoptar criterios para poder diferenciar entre ellos (por ejemplo, valores por omisi6n). 


Una vez terminada esta parte del andlisis sabemos si la tabla pertenece a una categorizacién o no, si perteneciera a 
una categorizacion se almacena en las estructuras de almacenamiento, y se analiza el resto de las claves foraneas 
que posee la tabla como si se tratase de una tabla que representa a una entidad referente. 


Determinar si corresponde a una entidad referente 
Entidad referente es una tabla que hace referencia a otras tablas (son las clasicas relaciones 1—N 0 1-1). 


Si llegamos a este punto sabemos que no nos encontramos frente a una tabla que representa a una entidad aislada y 
que tampoco corresponde a una categorizacion. Por lo tanto, ya se esta seguro de que esta tabla es una tabla 
referente dado que tampoco puede representar una relacién debido a que en una tabla que represente una relacién 
los atributos que forman la clave primaria de la tabla deben formar también al menos una clave foranea. 


Sabemos que cada clave foranea que posea la tabla representara una relacion binaria (debido a que es el unico tipo 
de relacidn que puede representarse sin utilizar una tabla) entre la tabla que nos encontramos analizando y la tabla 
a la cual hace referencia la clave foranea. Ademas sabemos que la cardinalidad de dicha relacion es 1-1, 0 bien 1— 
N, debido a que si fuese N—N se deberia haber representado por medio de una tabla. Finalmente también sabemos 
que la cardinalidad correspondiente a la tabla que nos encontramos analizando es 1. 


Analisis de una tabla que representa una relacion 


El andlisis de una relacién puede llegar a ser el mas complejo debido a la cantidad de casos diferentes que existen 
(recuerde que una tabla podria representar una relacién de N entidades, por lo tanto el ntimero de tablas que podria 
llegar a relacionar es variable e infinito). 


En todos los casos en los cuales una tabla representa una relacién nos es imposible determinar las totalidades y 
parcialidades de la relacidn. Si se prueba que la tabla es una relacion se coloca a esta junto con todos sus datos en 
nuestras estructuras de almacenamiento de relaciones (por ejemplo, nombre de la relaci6on, tablas que relaciona, 
cardinalidad, etc.). 


Relacion binaria 1-1 


Para explicar este caso plantearemos la siguiente situacion: dada las entidades A y B que se relacionan mediante 
una relacién con cardinalidad 1-1, tenemos que dado un elemento de A solo existe un elemento de B y dado un 
elemento de B solo existe un elemento de A. Ahora, para representar dicha situaci6n mediante una tabla sdlo existe 
una forma, y es la siguiente: una de las foraneas debe ser obligatoriamente la clave primaria (digo una porque 
recordemos que la clave primaria determina de forma tinica y minima a cualquier tupla de la relacién, y debido a 
que queremos representar una relacién 1-1), con eso representariamos una de las cardinalidades 1 (por ejemplo, la 
de A), pero atin nos falta representar la segunda cardinalidad 1 (siguiendo con el ejemplo la de B). Para realizar 
esto ultimo debemos hacer uso de las claves candidatas, es decir, debemos hacer que la segunda clave fordnea sea a 
su vez clave Unica (con esto representariamos que B también posee clave tinica). 


A continuacion se plantea un ejemplo para intentar clarificar este punto. 


Vehiculos Matriculas_Vehiculos Matriculas 


Nutmero_Vehiculo(PK)Numero_Matricula(FK) Nutimero_Vehiculo(PKFK) Nutmero_Matricula(PK) 


Obviamente la tabla Matriculas_Vehiculos intenta representar una relaciOn entre las entidades Vehiculos y 
Matriculas. Como vemos, Numero_Vehiculo es una clave foradnea y a su vez es clave primaria de la tabla, por lo 
que deducimos que la cardinalidad de Vehiculos es 1. Ahora, si queremos representar una relacion binaria 1-1 
debemos hacer que los atributos que componen a la otra clave foranea (en este caso Niimero_Matricula) ademas de 


fordneos sean unicos en la tabla. Con esto ultimo representariamos que Matriculas también posee cardinalidad 1 en 
la relacion. 


A continuacion presento un conjunto de tuplas para clarificar la necesidad de poseer la clave tinica. 


Vehiculos Matriculas_Vehiculos Matriculas Valido 
8946 Num_Veh: 8946Num_Mat: SAB 555 SAB 555 Si 
8946 Num_Veh: 8946Num_Mat: SAK 430 SAK 430 No 
1388 Num_Veh: 1388Num_Mat: SAK 430 SAK 430 No 


Como se ve en el ejemplo de tuplas anterior, existe una necesidad de especificar el atributo Nimero_Matricula 
como unico. 


En teoria deberiamos especificar las dos claves foraneas como unicas, pero debido a que la definicién de clave 
primaria es que es tnica y no nula, queda implicito que si una clave foranea debe ser a su vez clave primaria, 
entonces dicha clave foranea también es Unica. 


Relacion binaria N—1 / 1—-N 


En este tipo de relacidn solo poseemos dos claves foraneas. Para esta situacién, los atributos que componen la 
clave fordnea correspondiente a la entidad que posee cardinalidad N deben formar a su vez la clave primaria de la 
tabla. A diferencia de el caso anterior, los atributos que forman la clave fordnea correspondiente a la otra entidad 
NO pueden ser declarados como tnicos. 


Relacion binaria N-N 


A diferencia de los casos anteriores, este tipo de relacidn si puede formar agregaciones, y debemos hacer ciertas 
consideraciones antes de comenzar su analisis. 


Para representar este tipo de relacién siempre se debe utilizar una tabla, y los atributos que compongan las claves 
fordneas correspondientes a las dos tablas que relaciona deben formar a su vez la clave primaria de la tabla. 


En el caso que la clave primaria este formada por una sola clave fordnea, y que a su vez no todos los atributos de 
dicha clave foranea formen a la clave primaria, podemos considerar que se quiere representar a una entidad no 
representada (es decir, que dicha entidad existe en el modelo conceptual, pero no en el fisico y légico). 


A continuacion se presenta un caso sencillo de este tipo de relacion. 


Alumnos Asignaturas_Alumnos Asignaturas 


Ntmero_Alumno(PK)Numero_Asignatura(PKFK) Nutmero_Alumno(PKFK) Nutmero_Asignatura(PK) 


Se observa que la clave primaria de la tabla Asignaturas_Alumnos se encuentra formada por dos claves foradneas. 
Debido a que la tabla Asignaturas_Alumnos no posee ninguna clave fordnea a excepcion de las que componen a la 
clave primaria, deducimos rapidamente que nos encontramos frente a una relacién binaria N-N. 


Por lo tanto, la representacién conceptual de las tablas anteriores es la siguiente: 


El caso de ejemplo que planteamos anteriormente ilustra un caso tipico, en el cual podemos deducir sin 
ambigiiedades la cardinalidad y tipo de relacion existente, pero imaginese el siguiente caso: 


Alumnos Asignaturas_Alumnos 


Ntimero_Alumno(PK) Ntmero_Alumno (PKFK)Ntmero_Asignatura (PKFK) Numero_Semestre (FK) 


Asignaturas Semestres 


Numero_Asignatura (PK) Numero_Semestre (PK) 


La tabla Asignaturas_Alumnos posee las siguientes caracteristicas: la clave primaria de la tabla se compone por 
dos claves fordneas, pero ademas posee una clave fordnea que no compone a la primaria. Es obvio que nos 
encontramos frente a una tabla que representa una relacién, pero el problema es determinar el tipo de relacién 
existente. Si nos enfrentamos a un caso similar a este, se nos pueden plantear dos posibilidades que mostramos a 
continuacion: 


Caso 1: 


Caso 2: 


Como notara, existe una gran diferencia entre las dos posibilidades, debido a que la primera corresponde a una 
relacién binaria formando una agregacion, pero en el segundo caso la relacién es ternaria. Esta situacién se plantea 
debido a que si una relacién forma una agregacién que se relaciona con otra entidad, si dicha relacion (entre la 
agregacion y la entidad) posee cardinalidades 1-1 o N-1, existe la posibilidad de que no se represente la relacién 
por medio de una tabla. 


Para poder resolver este problema sélo tenemos dos posibilidades. La primera es examinando los atributos que 
forman la clave foranea que no compone la clave primaria de la tabla que representa la relacion y en el caso de que 
dichos atributos admitan valores nulos, entonces deducimos directamente que nos encontramos frente al caso de 
una agregacion, debido a que si fuese una relaci6n ternaria no deberia admitir valores nulos. Si la primer opcién 
falla, tenemos una ultima opcion y es intentar probar una relaci6n 1—1 cruzada entre la relacién y la entidad (en 
nuestro ejemplo entre la tabla Asignaturas_Alumnos y Semestres) en el caso de que probemos que existe una 
relaci6n 1—1 cruzada podemos decir con total seguridad que nos encontramos frente a una agregacion. 


Analisis de una relacion n—aria 


Si llegamos a este punto, sabemos con certeza de que la tabla representa una relacion, y que a su vez esta relacion 
no es binaria. Por ende, nos queda solo determinar si es 0 no una agregacion, y en el caso que no lo sea analizar las 
caracteristicas de la relacién (cardinalidad, entidades que relaciona, etc.). 


Para realizar este andlisis consideraremos que una relaci6n n—aria es una relacion que relaciona N entidades, 
siendo N un numero mayor que dos (esto lo haremos porque las binarias las analizamos en la secci6n anterior, pero 
no se debe perder de vista que una relacion binaria es un caso particular de una relacidn n—aria). A pesar de este 
hecho, existen tres posibilidades bien diferenciadas en una relacidn n—aria, vinculadas con sus cardinalidades: la 
primera es que todas sus cardinalidades sean uno, la segunda es que todas sus cardinalidades sean N y finalmente 
que sus cardinalidades sean una mezcla entre unos y enes. 


Relacion n—aria con todas sus cardinalidades N 


Si una tabla representa una relaci6n n—aria con todas sus cardinalidades N, entonces sabemos con certeza de que 
dicha tabla no posee claves tnicas para representar su cardinalidad (debido a que no necesita esto). 


Distinguir este tipo de relacidn es sumamente facil, debido a que para representar esta cardinalidad todas las claves 
fordneas que forman la relacién deben formar a su vez la clave primaria de la tabla. 


Ahora puede darse el caso de que se quiera representar una relaci6n entre varias entidades, en donde una de estas 
entidades no se represente tanto en el modelo l6gico como en el fisico. No tenemos duda que es una relacién n— 
aria con todas sus cardinalidades N, debido a que no posee claves tinicas y todas las claves foraneas forman la 
clave primaria. Pero no todos los atributos que componen a la clave primaria son fordneos, por lo tanto deducimos 
que existen entidades no representadas en el modelo fisico. Aqui se evaluaran dichos atributos segun los criterios 
que nosotros impongamos (por ejemplo, cada atributo es una entidad no representada, preguntar al usuario, etc.). 


A continuacion planteo un ejemplo, de una relacién n—aria con entidades no representadas: 


Tipos_de_Movimientos Conformes Tipos_Conformes 
: . Numero_Conforme Numero_Tipo (PKFK)Numero_Conforme 
Numero Tipo (FR) (PK) (PKFK)Fecha (PK) 


En las tablas anteriores, notamos que en la tabla Tipos_Conformes el atributo Fecha forma parte de la clave 
primaria de la tabla, pero no compone ninguna clave fordnea, por lo tanto deducimos que es una entidad no 
representada (no seria ldgico tener en el modelo fisico una tabla con todas las fechas posibles; en cambio, en el 
modelo conceptual si es itil y muchas veces necesario). 


La representacion conceptual de la tabla anteriormente expuesta es la siguiente: 


Relacion n—aria con todas sus cardinalidades 1 


Para determinar si una relacion pertenece a este tipo debemos estudiar sus claves candidatas (es decir, sus claves 
unicas). En este caso sabemos que toda clave fordnea que pertenezca a una entidad que esta tabla relaciona se debe 
encontrar ya sea en la clave primaria o en alguna de sus claves unicas. 


A continuacion planteamos un ejemplo de este tipo de relacidn por medio de una relaci6n ternaria: 


Matriculas 


Nutmero_Matricula (PK) 


Departamentos 


Numero_Departamento 
(PK) 


En este caso existiran dos claves unicas ademas de la clave primaria. Dichas claves tnicas son 
(Numero_Matricula, Numero_Departamento) y (Numero_Vehiculo, Numero_Departamento). 


Vehiculos 


Nutmero_Matricula (PK) 


Matriculas_Vehiculos_Departamentos 


Numero_Matricula (PKFK)Numero_Vehiculo 


(PKFK)Nutmero_Departamento (FK) 


Entonces en este caso deducimos que la relacién es 1-1-1 debido a que al haber una clave fordnea que no es 
primaria, entonces sabemos que la cardinalidad de la entidad a la cual hace referencia dicha clave fordnea es 1. 
Ahora listamos todas las claves tinicas con los atributos que la componen. Para cada caso aquel atributo que no se 
encuentre en una clave unica y que nosotros sepamos que hace referencia a una entidad que relaciona la tabla, 
entonces sabemos con certeza que tiene cardinalidad 1, es decir, si Nimero_Matricula-Numero_Departamento 


componen una clave unica sabemos que Nuimero_Vehiculo tiene cardinalidad 1. 


Ahora pasaremos a justificar lo anterior con un ejemplo, ingresando algunas tuplas a las tablas de la relacién antes 


citada. 


Matriculas_Vehiculos_Departamentos 


Num_Mat 


SAK 445 
SAK 445 
SSD 320 


DFF 440 


Num_Veh 


4670 
890 
430 


4670 


Ntm_Dep 


10 
10 
11 


10 


Valido 


Debido a que Numero_Matricula, Numero_Vehiculo son clave primaria de la tabla, entonces deducimos que la 
entidad Departamentos tiene cardinalidad 1. 


Ahora, a partir del ejemplo que mostramos ingresando tuplas, deducimos que un valor de Numero_Vehiculo y 
Ntmero_Departamento estos solo pueden aparecer juntos en una misma tupla una sola vez en toda la tabla. Por 
ende estos dos atributos forman una clave unica, deduciendo entonces que la entidad Matriculas tiene cardinalidad 
1. De la misma forma ocurre con la entidad Vehiculos. 


Por lo tanto la representaci6n conceptual de este conjunto de tablas es la siguiente: 


Relacion n—aria con sus cardinalidades mezcladas 


Se entiende por cardinalidad mezclada la cardinalidad de la relacion no es ni todas uno ni todas enes, sino que la 
cantidad de cardinalidades unos y enes son variables. 


Para resolver este tipo de relaci6n, nuevamente haremos uso de las claves candidatas (claves unicas). El analisis lo 
haré basandome en un ejemplo. 


Personas Personas_Garantes 

Numero_Persona (PK) Numero_Persona_Garante (PK) 

Conformes Conformes_Personas 

Numero_Conforme Numero_Persona (PKFK)Numero_Conforme (PKFK)Numero_Persona_Garante 
(PK) (FK) 


Como podemos observar en los esquemas que describimos anteriormente, la tabla que representa la relacion tiene 
la siguiente clave primaria compuesta: Numero_Persona, Numero_Conforme; por lo cual deducimos directamente 
que la cardinalidad de la entidad Personas_Garantes es 1. 


Luego tras analizar las claves tnicas que posee la tabla deducimos que posee una clave tnica compuesta por los 
siguientes atributos: Nimero_Conforme, Numero_Persona_Garante, por lo cual deducimos que la entidad 
Personas también posee cardinalidad 1. Finalmente al no poseer mas claves tinicas llegamos a la conclusion de que 
la cardinalidad de esta relaci6n es 1-1-N. 


Conclusion del ejemplo 


Se ha podido observar todo el analisis exhaustivo que se ha realizado a través del cédigo fuente (disefio fisico), se 
puede obtener el disefio légico aplicando Ingenieria Inversa y también el Disefio Conceptual. 


Ingenieria Inversa de Interfaces de Usuario 


Muchos programas gozan de gran fiabilidad, capacidad de procesamiento, 
etc., pero sus disefadores han olvidado la comodidad y facilidad de uso del 
usuario final (usabilidad). En dichos casos es posible aplicar ingenieria 
inversa sobre la interfaz de usuario con objeto de mantener la l6gica interna 
del programa para obtener los modelos y especificaciones que sirvieron de 
base para la construccion de la misma, con objeto de tomarlas como punto 
de partida en procesos de ingenieria directa que permitan modificar dicha 
interfaz. 


En general, como resultado de este tipo de procesos se obtiene la relacion 
entre los distintos componentes de la interfaz de usuario, siendo interesante 
poder obtener aspectos especificos de modelo de interfaces por separado: 
modelo de tareas, modelo de presentacion,... No obstante, la consecucion 
de este objetivo depende en gran medida de la especificaci6n que se 
utilizara para generar la interfaz en su momento. 


Es importante indicar que una interfaz grafica de usuario de sustitucioén 
puede que no refleje la interfaz antigua de forma exacta (de hecho, puede 
ser totalmente diferente). Con frecuencia, merece la pena desarrollar 
metaforas de interacci6n nuevas. Por ejemplo, una solicitud de interfaz de 
usuario antigua en la que un usuario proporcione un factor superior (del 1 al 
10) para encoger o agrandar una imagen grafica. Es posible que una interfaz 
grafica de usuario disefada utilice una barra de imagenes y un rat6n para 
realizar la misma funcion. 


é Qué es Reingenieria del Software? 


Reingenieria del software se puede definir como: “modificacion de un 
producto software, o de ciertos componentes, usando para el analisis del 
sistema existente técnicas de Ingenieria Inversa y, para la etapa de 
reconstruccion, herramientas de Ingenieria Directa, de tal manera que se 
oriente este cambio hacia mayores niveles de facilidad en cuanto a 
mantenimiento, reutilizacidn, comprension o evaluacion.” 


Cuando una aplicacion lleva siendo usada afios, es facil que esta aplicacion 
se vuelva inestable como fruto de las multiples correcciones, adaptaciones o 
mejoras que han podido surgir a lo largo del tiempo. Esto deriva en que 
cada vez que se pretende realizar un cambio se producen efectos colaterales 
inesperados y hasta de gravedad, por lo que se hace necesario, si se prevé 
que la aplicacion seguira siendo de utilidad, aplicar reingenieria a la misma. 


Entre los beneficios de aplicar reingenieria a un producto existente se puede 
incluir: 


e Pueden reducir los riegos evolutivos de una organizacion. 

e Puede ayudar a las organizaciones a recuperar sus inversiones en 
software. 

e Puede hacer el software mas facilmente modificable 

e Amplia las capacidades de las herramientas CASE 

e Es un catalizador para la automatizaci6n del mantenimiento del 
software 

e Puede actuar como catalizador para la aplicacion de técnicas de 
inteligencia artificial para resolver problemas de reingenieria 


La reingenieria del software involucra diferentes actividades como son: 


e analisis de inventarios 

e reestructuracion de documentos 

e ingenieria inversa 

e reestructuracion de programas y datos 
¢ ingenieria directa 


con la finalidad de crear versiones de programas ya existentes que sean de 
mejor calidad y los mismos tengan una mayor facilidad de mantenimiento. 
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Figura 1. Pasos de la Reingenieria del Software 


Analisis de Inventarios 


Todas las organizaciones de software deberian tener un inventario de todas 
sus aplicaciones. El inventario tal vez no sea mas que un modelo en una 
hoja de calculo que contenga informacion que proporcione una descripcién 
detallada (tamanio, edad, importancia para el negocio) de las aplicaciones 
activas. 


Los candidatos a la reingenieria aparecen cuando se ordena esta 
informacion en funcion de su importancia para el negocio, longevidad, 
mantenibilidad actual y otros criterios localmente importantes. Es entonces 
cuando es posible asignar recursos a las aplicaciones candidatas para el 
trabajo de reingenieria. 


Es importante sefalar que el inventario debera visitarse con regularidad, el 


estado de las aplicaciones puede cambiar en funcion del tiempo y, como 
resultado, cambiaran las prioridades para la reingenieria. 


Reestructuracion de documentos 


La documentacion débil es la marca de muchos sistemas heredados. ¢ Pero 
que se hace acerca de ellos? ;Cuales son las opciones? Crear 
documentaci6n consume mucho tiempo, si el sistema funciona vivira con lo 
que tenga. La documentacion debe actualizarse pero se tiene recursos 
limitados. Se utiliza un enfoque de “documentar cuando se toque”. El 
sistema es crucial para el negocio y debe volver a documentarse por 
completo incluso en este caso un enfoque inteligente es recortar la 
documentacion a un minimo esencial. Cada una de estas opciones es viable. 
Una organizacion de software debe elegir la mas apropiada para cada caso. 


Ingenieria Inversa 


Este término tiene sus origenes en el mundo del hardware. Una cierta 
compania desensambla un producto de hardware competitivo en un 
esfuerzo por comprender los “secretos” del disefio y fabricaci6n de su 
competidor. Estos secretos se podran comprender mas facilmente si se 
obtuvieran las especificaciones de diseno y fabricacién del mismo. Pero 
estos documentos son privados, y no estan disponibles para la compafnia 
que efectua la ingenieria inversa. En esencia, una ingenieria inversa con 
éxito precede de una o mas especificaciones de disefio y fabricacién para el 
producto, mediante el examen de ejemplos reales de ese producto. 


La ingenieria inversa del software es algo similar. En la mayoria de los 
casos, el programa del cual hay que hacer una ingenieria inversa no es el de 
un rival, sino, mas bien, el propio trabajo de la compania. Los “secretos” 
que hay que comprender resultan incomprensibles porque nunca se lleg6 a 
desarrollar una especificaci6n. Consiguientemente, la ingenieria inversa del 
software es el proceso de analisis de un programa con el fin de crear una 
representaciOn de programa con un nivel de abstracci6n mas elevado que el 
codigo fuente. 


La Ingenieria inversa es un proceso de recuperacion de disefio. Con las 
herramientas de la ingenieria inversa se extraera del programa existente 
informacion del disefio arquitectdnico y de proceso, e informacion de los 
datos. 


Reestructuracion de codigo 


El] tipo mas comun de reingenieria es la reestructuracion de cddigo, se 
puede hacer con moddulos individuales que se codifican de una manera que 
dificultan comprenderlos, probarlos y mantenerlos. 


Llevar a cabo esta actividad requiere analizar el cédigo fuente empleando 
una herramienta de reestructuracion, se indican las violaciones de las 
estructuras de programacion estructurada, y entonces se reestructura el 
codigo (esto se puede hacer automaticamente). El codigo reestructurado 
resultante se revisa y se comprueba para asegurar que no se hayan 
introducido anomalias. Se actualiza la documentacion interna del cédigo. 


Reestructuracion de datos 


La reestructuracion de datos es una actividad de reingenieria a gran escala. 
En la mayoria de los casos, la reestructuracion de datos comienza con una 
actividad de ingenieria inversa. La arquitectura de datos actual se analiza 
con minuciosidad y se define los modelos de datos necesarios, se 
identifican los objetivos de datos y los atributos, y después se revisa la 
calidad de las estructuras de datos existentes. 


Cuando la estructura de datos es debil (por ejemplo, actualmente se 
implementan archivos planos, cuando un enfoque relacional simplificaria 
muchisimo el procesamiento), se aplica una reingenieria a los datos. 


Dado que la arquitectura de datos tiene una gran influencia sobre la 
arquitectura del programa, y tambien sobre los algoritmos que lo pueblan, 
los cambios en datos daran lugar invariablemente a cambios o bien de 
arquitectura o bien de codigo. 


Ingenieria directa 


En un mundo ideal, las aplicaciones se reconstruyen utilizando un “motor 
de reingenieria” automatizado. En el motor se insertaria el programa viejo, 
que lo analizaria, reestructuraria y después regeneraria la forma de exhibir 
los mejores aspectos de la calidad del software. Después de un espacio de 
tiempo corto, es probable que llegue a aparecer este “motor”, pero los 
fabricantes de CASE han presentado herramientas que proporcionan un 


subconjunto limitado de estas capacidades y que se enfrentan con dominios 
de aplicaciones especificos. Lo que es mas importante, estas herramientas 
de reingenieria cada vez son mas sofisticadas. 


La ingenieria directa no solo recupera la informacion de disefio a partir del 
software existente, también utiliza esta informacion para alterar o 
reconstruir el sistema existente con la finalidad de mejorar su calidad 
global. En la mayoria de los casos el software sometido a reingenieria 
vuelve a implementar la funcién del sistema existente y también afade 
nuevas funciones 0 mejoras. 


Procesos involucrados en la Reingenieria del Software 


La reingenieria debe ser entendida como un proceso mediante el cual se 
mejora un software existente haciendo uso de técnicas de ingenieria inversa 
y reestructuracion de cédigo. 


Para llevar a cabo la reingenieria del Software se puede realizar a través del 
modelo Ciclico. Este modelo define seis actividades las cuales se muestran 
en la figura de abajo. En algunas ocasiones, estas actividades se producen 
de forma secuencial y lineal, pero esto no siempre es asi. Por ejemplo, 
puede ser que la ingenieria inversa (la comprension del funcionamiento 
interno de un programa) tenga que producirse antes de que pueda comenzar 
la reestructuraci6n de documentos. 
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Figura 1. Modelo Ciclico de la Reingenieria del Software 


El paradigma de la reingenieria mostrado en la figura es un modelo ciclico. 
Esto significa que cada una de las actividades presentadas como parte del 
paradigma pueden repetirse en otras ocasiones. Para un ciclo en particular, 
el proceso puede terminar después de cualquier de estas actividades. 


Analisis de inventario 


Todas las organizaciones de software deberan disponer de un inventario de 
todas sus aplicaciones. El inventario puede que no sea mas que una hoja de 
calculo con la informacion que proporciona una descripcion detallada (por 


ejemplo: tamano, edad, importancia para el negocio) de todas las 
aplicaciones activas. 


Los candidatos a la reingenieria aparecen cuando se ordena esta 
informacion en funcion de su importancia para el negocio, longevidad, 
mantenibilidad actual y otros criterios localmente importantes. Es entonces 
cuando es posible asignar recursos a las aplicaciones candidatas para el 
trabajo de reingenieria. 


Es importante destacar que el inventario debera revisarse con regularidad. 
El estado de las aplicaciones (por ejemplo, la importancia con respecto al 
negocio) puede cambiar en funci6n del tiempo y, como resultado, 
cambiaran también las prioridades para la reingenieria. 


Reestructuracion de documentos 


Una documentacion escasa es la marca de muchos sistemas de informacion 
heredados. ¢Qué se puede hacer al respecto? 


e Opcion 1: La creacién de documentaci6n consume muchisimo tiempo. 
El sistema funciona, y ya nos ajustaremos con lo que se tiene. En 
algunos casos, éste es el enfoque correcto. No es posible volver a crear 
la documentacion para cientos de programas de computadoras. Si un 
programa es relativamente estatico esta llegando al final de vida util, y 
no es probable que experimente muchos cambios. 

e Opcion 2: Es preciso actualizar la documentacion, pero se dispone de 
recursos limitados. Se utilizara un enfoque “del tipo documentar si se 
modifica”. Quiza no es necesario volver a documentar por completo la 
aplicacion. Mas bien se documentardan por completo aquellas partes del 
sistema que estén experimentando cambios en ese momento. La 
colecci6n de documentos util y relevante ira evolucionando con el 
tiempo. 

e Opcion 3: El sistema es fundamental para el negocio, y es preciso 
volver a documentarlo por completo. En este caso, un enfoque 
inteligente consiste en reducir la documentacion al minimo necesario. 


Todas y cada una de estas opciones son viables. Las organizaciones del 
software deberan seleccionar aquella que resulte mas adecuada para cada 
caso. 


Ingenieria inversa 


El término “ingenieria inversa” tiene sus origines en el mundo del 
hardware. Una cierta compania desensambla un producto de hardware 
competitivo en un esfuerzo por comprender los “secretos” del disefio y 
fabricacion de su competidor. Estos secretos se podran comprender mas 
facilmente si se obtuvieran las especificaciones de disefo y fabricacion del 
mismo. Pero estos documentos son privados, y no estan disponibles para la 
compania que efecttia la ingenieria inversa. En esencia, una ingenieria 
inversa con éxito precede de una 0 mas especificaciones de diseno y 
fabricacion para el producto, mediante el examen de ejemplos reales de ese 
producto. 


La ingenieria inversa del software es algo bastante similar. Sin embargo, en 
la mayoria de los casos, el programa del cual hay que hacer una ingenieria 
inversa no es el de un rival, sino, mas bien, el propio trabajo de la compafiia 
(con frecuencia efectuado hace muchos afios). Los “secretos” que hay que 
comprender resultan incomprensibles porque nunca se llego a desarrollar 
una especificacién. Consiguientemente, la ingenieria inversa del software es 
el proceso de andalisis de un programa con el fin de crear una representacion 
de programa con un nivel de abstraccion mas elevado que el cddigo fuente. 
La ingenieria inversa se extraera del programa existente informacion del 
diseno arquitectdnico y de proceso, e informacion de los datos. 


Reestructuracion del codigo 


El tipo mas comtn de reingenieria es la reestructuracion del cédigo. 
Algunos sistemas heredados tienen una arquitectura de programa 
relativamente sdlida, pero los mdédulos individuales han sido codificados de 
una forma que hace dificil comprenderlos, comprobarlos y mantenerlos. En 
estos casos, se puede reestructurar el codigo ubicado dentro de los médulos 
sospechosos. 


Para llevar a cabo esta actividad, se analiza el codigo fuente mediante una 
herramienta de reestructuracion, se indican las violaciones de las estructuras 
de programacion estructurada, y entonces se reestructura el cddigo (esto se 
puede hacer automaticamente). El codigo reestructurado resultante se revisa 
y se comprueba para asegurar que no se hayan introducido anomalias. Se 
actualiza la documentacion interna del cdédigo. 


Reestructuracion de datos 


Un programa que posea una estructura de datos débil sera dificil de adaptar 
y de mejorar. De hecho, para muchas aplicaciones, la arquitectura de datos 
tiene mas que ver con la viabilidad a largo plazo del programa que el propio 
codigo fuente. 


A diferencia de la reestructuracion de cédigo, que se produce en un nivel 
relativamente bajo de abstraccion, la estructuraciOn de datos es una 
actividad de reingenieria a gran escala. En la mayoria de los casos, la 
reestructuraci6n de datos comienza por una actividad de ingenieria inversa. 
La arquitectura de datos actual se analiza minuciosamente y se definen los 
modelos de datos necesarios. Se identifican los objetos de datos y atributos 
y, a continuacion, se revisan las estructuras de datos a efectos de calidad. 


Cuando la estructura de datos es debil (por ejemplo, actualmente se 
implementan archivos planos, cuando un enfoque relacional simplificaria 
muchisimo el procesamiento), se aplica una reingenieria a los datos. 


Dado que la arquitectura de datos tiene una gran influencia sobre la 
arquitectura del programa, y también sobre los algoritmos que los pueblan, 
los cambios en datos daran lugar invariablemente a cambios o bien de 
arquitectura o bien de codigo. 


Ingenieria directa 


En un mundo ideal, las aplicaciones se reconstruyen utilizando un “motor 
de reingenieria” automatizado. En el motor se insertaria el programa viejo, 
que lo analizaria, reestructuraria y después regeneraria la forma de exhibir 
los mejores aspectos de la calidad del software. Después de un espacio de 


tiempo corto, es probable que llegue a aparecer este “motor”, pero los 
fabricantes de CASE han presentado herramientas que proporcionan un 
subconjunto limitado de estas capacidades y que se enfrentan con dominios 
de aplicaciones especificos (por ejemplo, aplicaciones que han sido 
implementadas empleando un sistema de bases de datos especifico). Lo que 
es mas importante, estas herramientas de reingenieria cada vez son mas 
sofisticadas. 


La ingenieria directa, que se denomina también renovacion o reclamacion, 
no solamente recupera la informacion de disefio de un software ya 
existente, sino que, ademas, utiliza esta informacion en un esfuerzo por 
mejorar su calidad global. En la mayoria de los casos, el software 
procedente de una reingenieria vuelve a implementar la funcionalidad del 
sistema existente, y aflade ademas nuevas funciones y/o mejora el 
rendimiento global. 


Valoraciones sobre la Reingenieria del Software 


Se entiende por reingenieria la modificaci6n de un producto software o de 
ciertos componentes, usando para el analisis del sistema existente técnicas 
de ingenieria inversa y para la etapa de reconstruccion, herramientas de 
ingenieria directa. 


La reingenieria requiere tiempo; conlleva un coste de dinero enorme y 
absorbe recursos que de otro modo podrian emplearse en preocupaciones 
mas inmediatas. La reingenieria es una actividad que absorbera recursos de 
las tecnologias de la informacion durante un periodo de tiempo grande. 


Ante la perspectiva de aplicar procesos de reingenieria, cabe preguntarse si 
existen alternativas a esto: 


e Comprar un software que lo sustituya. 
e Desarrollar el software de nuevo. 


Desde luego, cualquier opcion (incluyendo la reingenieria) incurre en costes 
de mantenimiento y de operaciones. No obstante, la reingenieria se suele 
considerar una buena opcion frente al desarrollo de una nueva aplicacion 
cuando: 


e La aplicacion tiene fallos frecuentes que son dificiles de localizar. 

e La aplicacion es poco eficiente, pero realiza la accion esperada. 

e Existen dificultades para integrar la aplicacion con otros sistemas. 

e El software final de la aplicaci6n es de poca calidad. 

e Cuando no se dispone de personal suficiente para realizar todas las 
modificaciones necesarias que puedan surgir. 

¢ Cuando no se tenga facilidad para realizar las pruebas a los cambios 
que se deban realizar. 

e Cuando el mantenimiento de la aplicacion consume muchos recursos. 

e Cuando es necesario incluir nuevos requisitos a la aplicacion, pero los 
fundamentales se mantienen. 


Método cuantitativo 


De manera objetiva, se puede calcular el beneficio cuantitativo tanto para 
comprar un software que lo sustituya como para el desarrollo del software 
nuevo. 


Si se mantiene el software como esta, el beneficio se puede calcular de la 
siguiente manera: 


BM = [VA — (CMA + COpA)] x T. Vida 
Siendo 

BM: el beneficio de mantenimiento 

VA: el valor de negocio actual (anual) 
CMA: el coste de mantenimiento actual 


COpA: el coste actual de operacion de la aplicaci6n, es decir, los costes 
derivados de mantener la aplicacion en uso (servicios de atencion al cliente, 
administracion....). 


Si por el contrario se elige hacer reingenieria, el beneficio obtenido sera: 
BR = [(GF x T. Vida) — (CR x FR)]- BM 

GF = VE - (CMF x COpF)] - BM 

T. Vida = T. Vida Estimado —T. Reingenieria 

Donde: 

BR: beneficio de reingenieria 

GF: ganancia final 

CR: coste de reingenieria 


FR: factor de riesgo de la reingenieria 


BM: beneficio de mantenimiento 
VF: el valor de negocio tras la reingenieria (anual) 
CMF: coste de mantenimiento final 


COpF: coste de operacion final 


Importancia de aplicar Reingenieria del Software 


Mucha gente al ver las grandes y viejas mansiones queda asombrado de su 
belleza, pero no se preguntan que tan bien se puede vivir en ellas. Las 
personas que lo hacen dicen que es una pesadilla mantenerlas. Todas ellas 
fueron construidas con viejas tecnologia estandar. Sus paredes externas no 
tienen aislamiento. El alambrado eléctrico tiene limitaciones y claramente 
es inadecuada para las necesidades de energia de hoy y su cableado 
decadente crea un severo peligro eléctrico. 


Los viejos sistemas son muy similares a los grandes y viejos edificios. Ellos 
tienen los mismos problemas de mantenimiento, un hecho en gran parte 
irreconocible por parte de la comunidad corporativa. Muchos de esos 
edificios son demolidos por que no son mantenibles y ya no sirven para las 
necesidades de sus ocupantes. 


Las viejas computadoras tal vez se puedan ver solamente en museos. Pero 
en muchos casos, software escrito para viejos modelos de computadora 
estan ejecutandose hoy en dia. Un caso extremo es el de un software escrito 
para una IBM 1401 Autocoder. Cuando la compania remplazo la 1401 con 
una IBM 360/40, compraron un emulador de la 1401 para poder ejecutar el 
software. Esa aplicacion hoy dia corre en una PC — la compafiia compro 
otro emulador. 


Los clientes demandan que las nuevas capacidades sean agregadas al 
codigo escrito en sus viejos sistemas. Casi siempre, las empresas 
encuentran que no pueden modificar su cddigo — el programador que lo 
mantenia muri6 recientemente o nadie sabe programar en el lenguaje en el 
que fue escrito. Por lo que la funcionalidad de ese programa quedara asi 
para siempre. 


La siguiente lista son las razones por las que es aplicable la reingenieria a 
los sistemas de informacion heredados: 


e Frecuentes fallas de produccion (fiabilidad cuestionable). 
e Problemas de rendimiento. 

e Tecnologia obsoleta. 

e Problemas de integracion del sistema. 

¢ Codigo de calida pobre. 

e Dificultad (peligroso) al cambio. 

e Dificultad para probar. 

e Mantenimiento caro. 

e Incremento de problemas del sistema. 


Estas razones pueden ser solucionadas al aplicar un proceso de 
mantenimiento de software, pero cuando dicho mantenimiento deja de ser 
viable, entonces se toma la decision de aplicar reingenieria. 


Aunque la reingenieria se usa principalmente durante el mantenimiento del 
software, va mas alla de una simple ayuda para el mantenimiento. La 
reingenieria es el puente desde viejas tecnologias hacia nuevas tecnologias 
que las organizaciones deben usar en la actualidad para responder al cambio 
de requerimientos del negocio. 


Los viejos programas representan la tecnologia del ayer. Ahora sabemos 
que los afios tienen cuatro digitos y no dos, que los datos pueden ser 
manejados mejor en bases de datos y que tenemos nuevos disefos de 
construccién y lenguajes de programacion que permiten disenar programas 
notablemente mantenibles. 


Cuando el costo de mantener viejos edificios es altamente excesivo, se 
remplazan estos edificios. Nosotros deberiamos hacer lo mismo con los 
programas. Los programas no se hacen obsoletos al paso del tiempo ya que 
fueron escritos para hardware y sistemas operativos que ya no existen, 
muchos estan llenos de caracteristicas y parches no documentados. Sdélo 
cuando hayamos aprendido a que es mejor invertir en nuevo hardware y 
nuevos edificios podremos reconocer el valor de remplazar los viejos 
sistemas raquiticos. 


éQué es Reestructuracion del Software? 


La reestructuracion del software modifica el cédigo fuente y/o los datos en 
un intento de adecuarlo a futuros cambios. Tiende a centrarse en los detalles 
de diseno de modulos individuales y en estructuras de datos locales 
definidas dentro de los médulos. 


Los beneficios de de la reestructuracion son: 


e Programas de mayor calidad con mejor documentacion y menos 
complejidad, y ajustados a las practicas y estandares de la ingenieria 
del software moderno. 

e Reduce la frustracion entre ingenieros del software que deban trabajar 
con el programa, mejorando por tanto la productividad y haciendo mas 
sencillo el aprendizaje. 

e Reduce el esfuerzo requerido para llevar a cabo las actividades de 
mantenimiento. 

e Hace que el software se mas sencillo de comprobar y depurar. 


La reestructuraciOn se produce cuando la arquitectura basica de la 
aplicacion es solida, atin cuando sus interioridades técnicas necesiten un 
retoque. Comienza cuando existen partes considerables del software que 
son utiles todavia y solamente existe un subconjunto de todos los médulos y 
datos que requieren una extensa modificacion. 


Los tipos de reestructuracion, basicamente son 2: del cddigo y de datos. 


Reestructuracion del codigo 


La reestructuracion del cddigo se lleva a cabo para conseguir un diseno que 
produzca la misma funci6n pero con mayor calidad que el programa 
original. 


El objetivo es tomar el cddigo de forma de "plato de espaguetis" y derivar 
un disefio de procedimientos que se ajuste a la filosofia de la programacion 
estructurada. 


Reestructuracion de datos 


Analisis del codigo fuente, en primer lugar se evaluaran todas las sentencias 
del lenguaje de programacion con definiciones de datos, descripciones de 
archivos, de E/S, y descripciones de interfaz. Esta actividad a veces se 
denomina analisis de datos. 


Una vez finalizado el analisis de datos, comienza el rediseno de datos. En 
su forma mas sencilla se emplea un paso de estandarizacion de rediseno de 
datos que clarifica las definiciones de datos para lograr una consistencia 
entre nombres de objetos de datos, o entre formatos de registros fisicos en 
el seno de la estructura de datos o formato de archivos existentes. Otra 
forma de redisenio, denominada racionalizacion de nombres de datos, 
garantiza que todas las convenciones de denominacion de datos se ajusten a 
los estandares locales, y que se eliminen las irregularidades a medida que 
los datos fluyen por el sistema. 


Cuando la reestructuracion sobrepasa la estandarizacion y la 
racionalizacion, se efectiian modificaciones fisicas en las estructuras de 
datos ya existentes con objeto de hacer que el disefio de datos sea mas 
efectivo. Esto puede significar una conversion de un formato de archivo a 
otro, 0, en algunos casos, una conversion de un tipo de base de datos a otra. 


éQué es Refactoring? 


Refactoring es un tipo de reestructuracion de cddigo que se aplica en 
desarrollos orientados a objetos y que se define como “el proceso de 
cambiar el software de un sistema de manera que no altere su 
comportamiento externo pero mejorando su estructuracion interna” 
(Fowler[footnote], 2000). 

Fowler, M. (2000) Refactoring: Improving the design of existing code. 
Addison-Wesley.Pagina de M.Fowler sobre refactoring y catalogo de 
técnicas: http://www.refactoring.com/ 


Como cualquier reestructuracion de cédigo, el refactoring tiene como 
objetivo limpiar el cédigo para que sea mas facil de entender y modificar. 
Esta accion consigue, como efecto lateral, mejorar el diseno del software y 
ayudar a encontrar errores ocultos que puede que no hayan salido a la luz 
todavia. 


Existen una enorme variedad de técnicas para hacer refactoring (Fowler, 
2000), que pueden agruparse en las siguientes categorias: 


1. (Re)Composicién de métodos. En esta categoria se incluyen las 
técnicas para que se basan en acortar métodos demasiado largos (de 
acuerdo a la funcionalidad), sustituir llamadas a los métodos por su 
codigo, etc. 

2. Movimiento de caracteristicas entre clases. Bajo esta categoria se 
incluyen técnicas para reasignar las responsabilidades de una clase a 
otra, por ejemplo, separar una clase en varias, eliminar una clase, 
introducir uno 0 mas nuevos métodos a una clase, etc. 

3. Reorganizacion de datos. Esta categoria incluye las técnicas de 
refactoring que permiten facilitar el trabajo con datos, como la 
creacion de accesotes para consultar los propios atributos dentro de 
una clase, reemplazar ciertas estructuras de datos por objetos, 
reemplazar literales por constantes, etc. 

4. Simplificacion de expresiones condicionales. Esta familia de técnicas 
pretende facilitar la comprension, depuraci6n y mantenimiento del 
software mediante la simplificacién de las estructuras condicionales, 
por ejemplo dividiendo una condicional compleja en varias, 


eliminando expresiones condicionales redundantes en estructuras 
complejas, etc. 

5. Simplificacién de las llamadas a los métodos. Las técnicas de esta 
categoria pretenden simplificar la interfaz de una clase para que sea 
mas facil de usar. Incluye algunos refactorings como cambiar el 
nombre de métodos, eliminar o afadir parametros a las signaturas de 
los métodos, etc. 


Reorganizacion de la jerarquia generalizacion. Bajo esta categoria se 
engloban las técnicas que permiten mover métodos a lo largo de la jerarquia 
de herencia, como afadir un método de subclases a una superclase, afadir 
constructores a las superclases o dotar su cuerpo de mayor funcionalidad, 
crear nuevas sub/superclases, etc. 


Metafora de los dos sombreros 


Lo ideal es hacer el refactoring sobre la marcha, segun se va escribiendo 
codigo. La idea la explica perfectamente la metafora de los dos sombreros. 
Segun esta metafora, un programador tiene a su disposici6n dos sombreros. 
Uno de ellos etiquetado "hacer cédigo nuevo", y el otro con la etiqueta 
"arreglar codigo". 


Cuando empieza a programar, se pone el sombrero de "hacer cédigo 
nuevo". Se pone a programar hasta que tiene hecha alguna parte del 
programa y le hace una primera prueba, compilando y viendo que funciona. 
Deja esa parte del programa funcionando. Sigue con el mismo sombrero 
puesto y se prepara para seguir haciendo su programa. En ese momento ve 
un trozo de cédigo que podria reaprovechar si estuviera separado en otra 
funcion o ve cualquier otra cosa que si estuviera hecha de otra forma, le 
facilitaria la tarea de seguir con su programa. O simplemente ve algo que no 
le convence como esta hecho. En ese momento se cambia el sombrero. Se 
quita el de "hacer cédigo nuevo" y se pone el de "arreglar cédigo". 


Ahora solo esta arreglando el codigo. No mete nada nuevo. Echa un rato 
cambiando cddigo de sitio, haciendo métodos mas pequefos, etc, etc. Al 
final deja el cédigo funcionando exactamente igual que antes, pero hecho 


de otra manera que le facilita seguir con su trabajo. Nuevamente se cambia 
el sombrero por el de "hacer codigo nuevo" y sigue programando. 


La idea es hacer codigo nuevo a ratos, arreglar codigo existente a ratos. 
Tener claramente qué se esta haciendo en cada momento. Si afladimos 
codigo nuevo, NO arreglamos el existente. Si estamos arreglando el 
existente, NO anadimos funcionalidades nuevas. La idea también es 
arreglar el codigo con frecuencia, cada vez que veamos que algo no esta 
todo lo bien hecho que debiera. Es decir, hacer refactoring 
sistematicamente. 


Ventajas de hacer Refactoring 


Cualquier programador con un poco de experiencia sabe que nunca se 
disena bien el codigo a la primera, que nunca nos dicen al principio todo lo 
que tiene que hacer el cédigo, que nuestros jefes, segun vamos 
programando y van viendo el resultado van pidiendo cosas nuevas o 
midificaciones, etc. 


El] resultado de esto es que nuestro cddigo, al principio, puede ser muy 
limpio y estar bien organizado, siguiendo un disefio mas o menos claro. 
Pero segtin afadimos cosas y modificaciones, cada vez se va "liando" mas, 
cada vez se entiende pero y cada vez nos cuesta mas depurar errores. 


Si vamos haciendo refactoring sistematicamente cada vez que veamos 
codigo feo, el cédigo se mantiene mas elegante y mas sencillo. En fases 
mas avanzadas de nuestro programa, seguira siendo un codigo legible y 
facil de modificar o de afiadirle cosas. 


Aunque inicialmente parece una pérdida de tiempo arreglar el codigo, al 
final del mismo se gana dicho tiempo. Las modificaciones y afadido tardan 
menos y se pierde mucho menos tiempo en depurar y entender el cédigo. 


